Design Comments: A code specifying the major category of the Identified Entity Role as defined by HL7 vocabulary.

UsageNotes: http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/RoleClass.htm

Rationale: Provides a means to identify Roles played by entities

Design Comments: This identification attribute supports capture of a healthcare identifier specific to the client. This identifier may be assigned jurisdictionally or by care facility.

UsageNotes: At least 1 client identifier must be present in the message

Rationale: Populated attribute supports unique identification of the client.

Design Comments: Indicates the status of the Client role (e.g. Active)

Rationale: Populated attribute supports the identification of the client

Design Comments: An interval of time specifying the period during which this record in a client registry is in effect, if such time limit is applicable and known.

Rationale: Required attribute supports the identification of the client

Design Comments: A code that controls the disclosure of information about this client record.

UsageNotes: Data in the EHR may at some point (and in some jurisdictions) be accessed directly by patients. Some health information may be deemed inappropriate for direct access by patients and requires interpretation by a clinician (e.g. prescription of placebos, analysis of certain psychiatric conditions, etc) Even where direct access by patient is not provided, there may need to be guidance to other providers viewing the record where care should be used in disclosing information to the patient. Non-clinical data (e.g. demographics) may need to be flagged as not for disclosure to patient and or next of kin. There may be professional policy and or legislative guidelines about when/if records may be flagged as not for direct disclosure.

Rationale: Populated attribute supports the business requirement to provide restricted access where required

Design Comments: The Person class contains identifying and demographic data elements for the focal person similar to those in the HL7 v2.x PID segment such as name, gender, date of birth, deceased indicator and time.

Rationale: Provides additional demographic data elements for the focal class IdentifiedEntity

Design Comments: An HL7 defined value representing the class or category that the Entity instance represents. Examples: Person, Animal, Chemical Substance, Group, Organization

UsageNotes: http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/EntityClass.htm

Rationale: Due to the extremely large number of potential values for a code set representing all physical things in the universe, the class code indicates both the subtype branch of the Entity hierarchy used as well as a high level classifier to represent the instance of Entity. This can be used to constrain the eligible value domains for the Entity.code attribute.

Design Comments: An HL7 defined value representing whether the Entity represents a kind-of or a specific instance.

Examples: 1 human being (an instance), 3 syringes (quantified kind) or the population of Indianapolis (kind of group)

UsageNotes: http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/EntityDeterminer.htm

Rationale: An Entity may at times represent information concerning a specific instance (the most common), a quantifiable group with common characteristics or a general type of Entity. This code distinguishes these different representations.

Design Comments: Name(s) for the Client

Rationale: Populated attribute supports the identification of the client

Design Comments: Provides information about telecom

Rationale: Required attribute supports the identification of the client

Design Comments: Gender of the Client, this is not to be confused with Clinical Gender of a client. Administrative Gender is typically restricted to Male (M), Female (F) or Undifferentiated (UN)

Rationale: Populated attribute supports the identification of the client

Design Comments: Date of birth of the Client

Rationale: Populated attribute supports the identification of the client

Design Comments: An indication that the client is deceased. Appropriate business process/function will need to be employed to ensure that validation or verification of the death event has been established prior to populating the message.

Rationale: Required attribute supports the identification of the client

Design Comments: The date and time that a client's death occurred

Rationale: Required attribute supports verification of death from official source such as Vital Statistics.

Design Comments: An indication as to whether the client is part of a multiple birth.

Rationale: Required attribute supports the identification of the client

Design Comments: The order in which this client was born if part of a multiple birth.

Rationale: Required attribute supports the identification of the client

Design Comments: Address(es) of the Client

Rationale: Populated attribute supports the identification of the client

Design Comments: Identifiers used for the focal person by other organizations are sent in the OtherIDs class. The other organization can be sent in the E_Organization Entity Class

Rationale: Provides the ability to capture additional client identifiers that are not healthcare specific

Design Comments: Associations between persons in the Person Registry, such as spouse or parent, can be sent in a PersonalRelationship class. The exact nature of a association is described by the code attribute with a value drawn from the PersonalRelationshipRoleType domain. Most associations can be represented in either of two ways depending on who is the player and who is the scoper. For example, the association between a father and his daughter can be represented by a code of "father" where the parent is the player and the child is the scoper, or by a code of "daughter" where the child is the player and the parent is the scoper.

Rationale: Supports the business requirement to capture additional information about the Identified Client's Next of Kin

Design Comments: Information about what language(s) should be used to communicate with the focal person can be sent in the LanguageCommunication class.

Rationale: Supports the business requirement to identify languages used by client for the purposes of communication

Design Comments: A code specifying the major category of a Role as defined by HL7 vocabulary.

UsageNotes: http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/RoleClass.htm

Rationale: Provides a means to identify Roles played by entities

Design Comments: Other non-healthcare identifiers for the Client (e.g. Passport, SIN, DND, DIAND, Drivers License)

Rationale: Mandatory attribute supports the identification of the client

Design Comments: A pan Canadian code further specifying the kind of Role such as Drivers License, RCMP, DND, Social Insurance Number

Rationale: Populated attribute supports the identification of the client

Design Comments: The Organization responsible for issuing the Other ID identified in the OtherIDs Role Class

Rationale: Supports the requirement to supply additional information regarding the assigning Organization of the OtherID

Design Comments: An HL7 defined value representing the class or category that the Entity instance represents.

Examples: Person, Animal, Chemical Substance, Group, Organization

Rationale: Due to the extremely large number of potential values for a code set representing all physical things in the universe, the class code indicates both the subtype branch of the Entity hierarchy used as well as a high level classifier to represent the instance of Entity. This can be used to constrain the eligible value domains for the Entity.code attribute.

Design Comments: An HL7 defined value representing whether the Entity represents a kind-of or a specific instance.

Examples: 1 human being (an instance), 3 syringes (quantified kind) or the population of Indianapolis (kind of group)

Rationale: An Entity may at times represent information concerning a specific instance (the most common), a quantifiable group with common characteristics or a general type of Entity. This code distinguishes these different representations.

Design Comments: Unique identifier for the organization that assigned the non-healthcare identifier for the client.

Rationale: Mandatory attribute supports the identification of the organization assigning the identifier to the client

Design Comments: A name for the non-healthcare organization

Rationale: Populated attribute supports the identification of the organization assigning the identifier to the client

Design Comments: A code specifying the major category of a Role as defined by HL7 vocabulary.

UsageNotes: Links two people in a personal relationship. The character of the relationship must be defined by a PersonalRelationshipRoleType code. The player and scoper are determined by PersonalRelationshipRoleType code as well.

Rationale: Provides a means to identify Roles played by entities

Design Comments: A code further specifying the kind of Role such as Mother, Father, Natural Parent or Step Parent

Rationale: Mandatory attribute that supports understanding the relationship between the client and the ParentClient

Design Comments: The Parent Person class can send the person that is legally responsible for the care and management of the focal person. If the relationship (e.g., parent, spouse, unrelated friend) of the guardian to the focal person is of interest then a PersonalRelationship with the same persons as player and scoper should also be sent.

Rationale: Supports the business requirement to capture identification and demographic information regarding the Identified Client's Next of Kin

Design Comments: An HL7 defined value representing the class or category that the Entity instance represents.

Examples: Person, Animal, Chemical Substance, Group, Organization

UsageNotes: http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/EntityClass.htm

Rationale: Due to the extremely large number of potential values for a code set representing all physical things in the universe, the class code indicates both the subtype branch of the Entity hierarchy used as well as a high level classifier to represent the instance of Entity. This can be used to constrain the eligible value domains for the Entity.code attribute.

Design Comments: An HL7 defined value representing whether the Entity represents a kind-of or a specific instance. Examples: 1 human being (an instance), 3 syringes (quantified kind) or the population of Indianapolis (kind of group

UsageNotes: http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/EntityDeterminer.htm

Rationale: An Entity may at times represent information concerning a specific instance (the most common), a quantifiable group with common characteristics or a general type of Entity. This code distinguishes these different representations.

Design Comments: A unique identifier for the next of kin

Rationale: Populated attribute supports the identification of the next of kin and allows for the use of null flavours when the identifier is not known or available.

Design Comments: A name for the next of kin

Rationale: Required attribute supports the identification of the next of kin

Design Comments: A code indicating the language of communication

Rationale: Mandatory attribute conveying the expected language message elements are to be transmitted in.

Design Comments: Indicates the preferred language for all communications.

Rationale: Required attribute that supports the business requirement to indicate the preferred language for all communications.